1. Technical Field
The present invention relates generally to a system and method for defining and enforcing security restrictions with respect to portions of executable program code in a runtime environment. In particular, the present invention reduces the computational and administrative complexity associated with such security restrictions.
2. Description of the Related Art
JAVA™ (a trademark of Sun Microsystems, Inc.) is an object-oriented, compiled, multi-threaded computer language that generates platform-independent executable files.
JAVA™ is object-oriented. This means, in the simplest terms, that it allows for the association of member functions or “methods” within data structures. Indeed, all JAVA™ programs are made up solely of data structure types known as “classes,” where classes contain both data fields and methods.
Classes may “inherit” characteristics of other classes. When a “descendant” class inherits from another “ancestral” class (also referred to as a “base” class), it inherits all of the data fields and methods of the ancestral class. In addition, a descendent class may provide its own methods to supplement or take the place of ancestral class methods.
JAVA™ is compiled. That means that before a JAVA™ program (written as source code) can be executed, it must be processed by a compiler to make an executable form of the program. Executable JAVA™ programs are stored in “.class” files, with each “.class” file containing executable object code for a single JAVA™ class.
JAVA™ is multi-threaded. This means that a single JAVA™ program can have several sequences of code executing concurrently. Each of these sequences is known as a thread. Multi-threaded program languages, such as JAVA™, are very useful when writing software such as, for instance, communication software, where it is helpful to allow the software to perform other tasks while waiting for input.
JAVA™ produces platform-independent executables. When a JAVA™ program is compiled to produce “.class” files, those “.class” files are capable of being executed on any platform having a JAVA™ runtime environment. A JAVA™ runtime environment is a piece of software that allows a computer to executes JAVA™ “.class” files. JAVA™ runtime environments are available for many, if not most, commonly used computer platforms today.
There are essentially two kinds of JAVA™ runtime environments: interpreters and just-in-time compilers. Interpreters directly interpret the binary code contained in “.class” files and execute instructions corresponding to that binary code as the interpretation process is carried out. Just-in-time compilers, on the other hand, first translate the binary code into native instructions, then execute the native instructions. Native instructions are instructions that are designed to be executed directly by the computer's hardware.
JAVA™'s platform independence makes it particularly suitable for applications requiring portable program code. One of the prominent uses of JAVA™ is for writing applets. Applets are (generally small) programs that are intended to be embedded in web pages. Most modern web browsers support JAVA™ applets by providing a JAVA™ virtual machine (JVM) within the web browser. A special applet tag within the webpage source file tells the web browser to load and execute one or more “.class” files. The code contained within these “.class” files may also make use of standard JAVA™ library classes for performing standard operations, such as input/output, sorting, searching, and the like.
Executing portable code, especially in a web browser, raises a number of security concerns. Because JAVA™ is a general-purpose programming language with a complete set of input/output library classes and methods, a rogue applet having access to those library functions has the potential to cause a significant amount of damage to a computer system. An unsuspecting user could download such an applet by simply accessing a web page containing the applet, without even being aware of the existence of the applet, much less the damaging code contained within the applet.
The designers of the JAVA™ programming language were aware of this concern. When version 1.0 of the JAVA™ Developer's Kit (JDK) was released, severe restrictions were placed upon an applet's ability to perform input/output operations on the client machine. For example, early JAVA™ applets were unable to read or write files on the client machine. The limited execution environment that this early JAVA™ security model provided is typically referred to as “the sandbox.”
Later versions of JAVA™, starting with JAVA™ version 1.2 (also referred to as simply “Java 2”), employ a more sophisticated security model to allow enhanced functionality on the client side without compromising security. Under the JAVA™ 2 security model, “trusted” code can be given permission to perform certain sensitive operations, such as reading or writing files. Class files containing trusted code are authenticated using a digital signature scheme. In the JAVA™ 2 security object model, objects of class “CodeSource” are used to identify the source (by Uniform Resource Locator or “URL”) of a given JAVA™ class file and the cryptography keys (if any) that were used to sign that class file.
In JAVA™ 2 and subsequent releases of the JAVA™ programming language, the responsibility of enforcing which portions of code have certain permissions is assumed by an object instantiating the “SecurityManager” class. The SecurityManager works in conjunction with another object, an instantiation of the “AccessController” class, to determine whether a particular object or method has permission to access another object's data or invoke its methods.
Under the JAVA™ 2 security object model, a class of objects called “Permission” is used to establish rules regarding the permissions granted to particular methods or objects. Particular kinds of permissions are defined as subclasses of the base “Permission” class. Each of these subclasses has three properties: a type, a target name, and one or more optional actions. The “type” of the Permission is simply the name of the subclass of “Permission.” For example, “java.io.FilePermission” is the name given to one of the subclasses of “permission” that is defined in the standard JAVA™ library. The target name identifies a kind of resource or instance(s) of a resource to which the permission pertains. For example, in the case of a “java.io.FilePermission,” where the permission pertains to the ability to access a particular file, the target name would be the name of the file. Many other target names (such as “showWindowWithoutWarningBanner,” for example) are defined by the JAVA™ API specification. Programmers may choose to introduce their own target names for particular resources, as well. The optional “actions” associated with a “Permission” object denote particular operations permitted with respect to the resource identified by the target name. For example, an instance of java.io.FilePermission may be associated with a set of actions such as read, write, or delete, which may be performed with respect to the file identified by the target name.
A class called “policy” is used to define the security policy for the AccessController to follow. Typically, this is done by reading a “policy file” from disk, where the policy file defines the permissions associated with each code source. Specifically, the policy file defines what are referred to as protection domains, which are represented within the JAVA™ language as objects of class “ProtectionDomain.” A ProtectionDomain is a mapping from a CodeSource to a collection of Permissions. Each class in the JAVA™ virtual machine may belong to one and only one ProtectionDomain, which is set when the class is first defined.
Permissions are enforced by placing a call to the “checkpermission( )” method of the AccessController class in either the constructor or some other method of that class representing the protected resource. For example, a method that deletes a file may precede the actual file deletion code with a call to the “checkpermission( )” method of the AccessController class in order to determine whether the calling method has permission to delete that file.
The checkpermission( ) method verifies that the calling method has permission to delete the file by traversing the JAVA™ virtual machine's call stack to determine the protection domain of each calling method on the call stack. If each protection domain represented on the call stack contains the correct permission, checkpermission( ) terminates normally, and execution continues. If, on the other hand, one of the calling methods on the call stack has a protection domain that does not contain the requisite permission, an “AccessControlException” is thrown so as to indicate to the method seeking permission that that method does not have permission to perform the particular action.
Traversing the security policy data for each caller in the call stack to determine its protection domain is computationally intensive. Program call stacks can become exceedingly long, and the computation burden this imposes is multiplied by the number of permissions defined in each protection domain. This computational complexity can lead to degraded system performance.
Another challenge to providing a secure platform is experienced when installing new class files. When a new class file is installed, policy information needs to be updated to grant required permissions to this new class file. A new class file or program to be installed may come bundled with a policy file listing all the required permissions. A system administrator can make policy configurations and grant permissions to the new application accordingly. However, each permission requested by a new application must be examined carefully by a system administrator for compliance with organizational policy and security guidelines so that applications will not be granted permissions that may be exploited to compromise system integrity. This review process requires a detailed understanding of the operation environment and is subject to risk of human error.
What is needed, therefore, is a system and method for decreasing the complexity of defining and enforcing security restrictions on portions of executable program code in a runtime environment.